In wireless communication systems, wireless devices may move around within the coverage area of a wireless communication network. In order for a wireless device to communicate with a network node of the communication network, the wireless device needs to be known to the network, be synchronised with the network or the network node. Of course a plurality of other requirements needs to be fulfilled in order for the wireless device being able to communicate with the network.
In order for the wireless device to become known to the wireless communication and/or become synchronised with a network node of the wireless communication, the wireless device generally initiates a random access procedure. The random access procedure generally relies on the statistically low probability that very many wireless devices attempt to access the network simultaneously and that the probability is low that wireless devices that do attempt to access the network simultaneously select the same random access preamble. When such a preamble collision still occurs, the result is at best that one of the wireless devices succeeds to access the network. In the worst case, all the wireless devices using the same preamble in the same random access resource fail to access the network. A wireless device that fails the random access procedure has to restart the procedure. This has several adverse consequences, including increased radio resource consumption i.e. further strain on the random access resources, increased random access load, delayed network access and increased energy consumption in the wireless device.
During the random access procedure, a wireless device may transition from one mode/state to another mode/state, e.g. in Long Term Evolution, LTE, the wireless device may transition from RRC_IDLE state to RRC_CONNECTED state. The access control signalling when going from RRC_IDLE to RRC_CONNECTED state consists of a random access, RA, phase for synchronising with and gaining initial access to the wireless or cellular network and a further phase for authentication, configuring the connection, and establishing appropriate states on higher layers, e.g. through S1AP signalling between the network node, e.g. a eNB in an LTE network, and the Mobility Management Entity, MME and Non-Access Stratum, NAS, signalling between the wireless device, e.g. a User Equipment (UE) and the MME in Evolved Packet System, EPS/LTE. This network access procedure is illustrated in FIG. 1.
As can be seen from FIG. 1, the random access procedure in LTE consists of four steps:                1. The UE transmits a preamble on the Physical Random Access Channel, PRACH. Each cell has its own set of random access preambles (although preambles may be reused between (preferably not adjacent) cells). Optionally the preambles may be divided into two groups, A and B. The UE then selects the group to (randomly) pick a preamble from, based on the potential message size (i.e. the data available for transmission in step three of the random access procedure plus Medium Access Control, MAC, header and any possible MAC control elements) and the channel quality (estimated in terms of the measured downlink path loss). Two conditions have to be met for the UE to select a preamble from preamble group B: the potential message size has to exceed a certain threshold and the estimated path loss has to be lower than a certain threshold.        2. The eNB sends a Random Access Response, RAR to the UE using a broadcast identifier (RA-Radio Network Temporary Identifier, RNTI). As indicated in FIG. 2, the RAR packet Data Unit, PDU, may contain a backoff indicator, BI, and zero or more MAC RAR. Each MAC RAR contains a temporary identifier, a timing advance command, an uplink grant and a reserved bit, R (which is set to zero). The MAC PDU header contains one MAC subheader (Random Access Preamble ID, RAPID, subheader) for each MAC RAR that is included in the RAR PDU. Each such corresponding MAC subheader (RAPID subheader) includes a random access preamble identifier which indicates the received RA preamble that the corresponding MAC RAR pertains to. Hence, in this way each MAC RAR is mapped to a preamble (transmitted by the UE and received by the eNB in step 1) and Physical Random Access Channel, PRACH, resource (see FIGS. 2 and 3).        3. The UE transmits RA Msg3 containing a UE identity (in the RRCConnectionRequest message). Depending on the parameters in the UL grant received in step 2 this message is transmitted 6 or 7 subframes after the reception of the RAR (RA Msg2) in Frequency Division Duplex, FDD, mode. In Time Division Duplex, TDD, mode the timing also depends on the configuration of uplink, UL, and downlink, DL, subframes. The UE identity included in the RRCConnectionRequest message is the System Architecture Evolution—Temporary Mobile Subscriber Identity, S-TMSI, if it is available (which it typically is unless the UE is accessing the network from the DETACHED state), or a 40-bit random number, if no S-TMSI is available. The S-TMSI is a 40-bit temporary identity, which is allocated by the MME and which consists of the MME Group ID, MMEGI, and the MME Code, MMEC.        4. RA Msg3 is echoed in the downlink (together with an RRCConnectionSetup message) to conclude the contention resolution (resolving possible preamble collisions). Specifically, the contention is resolved through the identity contained in the UE Contention Resolution Identity MAC Control Element in RA Msg4. The contention resolution serves to resolve the following potential situation. If two (or more) UEs have happened to use the same random access preamble in the same PRACH resource (in step 1), they will both assume that they are the intended recipient of the Random Access Response (in step 2) and both will consequently send the RRCConnectionRequest message in RA Msg3 to the eNB (in step 3). The eNB will at best correctly receive one of these messages and by including the received UE identity in the response message to the UE (in step 4) the eNB indicates which of the UEs it is responding to.        
The fifth message (see FIG. 1), the RRCConnectionSetupComplete message is not really a part of the actual random access procedure (although it is a part of the RRC connection establishment procedure).
FIG. 4 illustrates the format of the UL grant in a MAC RAR. Frequency Hopping, FH, is a frequency hopping flag, which indicates whether frequency hopping should be used for the scheduled UL transmission. The Transmit Power Command, TPC, Command is a power control command for the scheduled UL transmission. In a non-contention based random access procedure the Channel State Information, CSI, Request bit may be used to request a channel quality report in conjunction with the scheduled UL transmission, but in contention based random access the field is reserved (unused). The UL Delay bit indicates one of two possible delays between the RAR and the scheduled UL transmission.
As stated above, two or more UEs may by chance use the same random access preamble in the same PRACH resource, thereby causing a random access collision situation. The risk for random access preamble collisions may be higher when the network access load is high. High access load may occur once in a while because the access load varies with the local circumstances and it is inevitable that access load peaks will occur, either by chance (a number of UEs just happen to attempt to access the network more or less simultaneously) or triggered by a specific situation (e.g. an event that causes a lot of people—and thus UEs—to gather in a relatively small area).
High access load scenarios may also be expected to be more common with the emergence of the connected devices and the vision of ubiquitous deployment of such. According to this vision, the future development of the communication in cellular networks comprises huge numbers of small autonomous devices, which typically, more or less infrequently, e.g. once per week to once per minute, transmit and receive only small amounts of data, or are polled for data. These devices are assumed not to be associated with humans, but are rather sensors or actuators of different kinds, which communicate with application servers (which configure the devices and receive data from them) within or outside the cellular network. Hence, this type of communication is often referred to as machine-to-machine, M2M, communication and the devices may be denoted machine devices, MDs. In the 3rd Generation Partnership Project, 3GPP, standardisation the corresponding alternative terms are machine type communication, MTC, and machine type communication devices, MTC devices, with the latter being a subset of the more general term UE.
The reason why realisation of this may be expected to make access load peaks more common is the predicted potentially large numbers of the devices in combination with the fact that a large portion of the devices are expected to be various kinds of sensor devices, whose communication may be triggered by events in the environment. This implies the risk that a large number of sensor devices are triggered by a common event and attempt to access the network more or less simultaneously.
Example scenarios include MTC devices in the form of sensor devices which monitor states of technological systems or processes or sensor devices monitoring various environmental aspects, such as temperature, pressure or vibrations. For such MTC devices (and applications) external events, such as a power grid failure, an earthquake, a pipeline damage or an industrial process failure, may trigger a large amount of relatively densely located MTC devices to attempt to access the cellular network more or less simultaneously for the purpose of reporting the triggering events to their respective application servers. Synchronised access bursts may also be caused by poor design or configuration of applications, e.g. involving synchronised periodic reporting from many MTC devices.
Besides the above described particular access overload/load peak threats seen from MTC devices and MTC applications, overload/load peaks may of course be caused also by regular (non-MTC) UEs, by themselves or in combination with the access load regularly caused by MTC devices. Such overload/load peak situations may thus occur even without extraordinary actions from the MTC devices in a cell. An example of such scenarios can be in a stadium-like environment, where many UEs are trying to access the network.
High access load peaks, or overloading of the access/random access resources can and will thus occur in more or less all parts of the network, unless the PRACH/random access resources are wastefully over dimensioned.
Note that the risk for random access preamble collisions is higher when the network access load is high and in these situations the increased random access load caused by the collisions—and the resulting random access reattempts—is particularly harmful, since it further escalates an already bad situation.